Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000045_owner-urn-ietf _Wed Oct 16 13:10:06 1996.msg

Internet Message Format | 1997-02-19 | 7KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA15907 for urn-ietf-out; Wed, 16 Oct 1996 13:10:06 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA15902 for <[e-mail]>; Wed, 16 Oct 1996 13:10:01 -0400
Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA15261  (mail destined for [e-mail]); Wed, 16 Oct 96 13:09:56 -0400
Received: from ifi.unizh.ch by josef.ifi.unizh.ch
          id <[e-mail]>; Wed, 16 Oct 1996 19:09:52 +0100
Subject: Re: [URN] Internationalization!
To: [e-mail]
Date: Wed, 16 Oct 1996 19:09:51 +0100 (MET)
Cc: [e-mail]
In-Reply-To: <96Oct12.233126pdt."2765"@golden.parc.xerox.com> from "Larry Masinter" at Oct 12, 96 11:31:26 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 5564
From: Martin J Duerst <[e-mail]>
Message-Id: <"josef.ifi..001:16.09.96.18.09.52"@ifi.unizh.ch>
Sender: [e-mail]
Precedence: bulk
Reply-To: Martin J Duerst <[e-mail]>
Errors-To: [e-mail]

When I received the anoucement for the new URN mailing list
some time ago, I thought that one point would definitely turn
up, namely internationalization. I had this expectation because
in an earlier discussion on the uri mailing list, I was told
that I came at a bad time, but that this could be dealt with
with URNs.

After following the discussion for some time, I realized that
a lot of issues have come up, but internationalization was never
mentionned. This is not a good sign, and I want to change it
herewith.

Internationalization, for those that don't know it, means
support for different scripts and languages as they are used
around the world. Internationalization is often abbreviated I18N.


Why is internationalization of URLs and URNs an issue?

- In some cases, URL/N contents is per definition international.
    Think about a query to a Japanese->English dictionary server.
- In some cases, resource locations (e.g. file names) contain
    non-ASCII characters. On some OSs, there is absolutely
    nothing strange about such things.
- Many names of resources (think about book titles) are inherently
    in various languages.
- Company names, product names, and so on, are much better known
    to local users in their local form. It is tedious and
    error-prone, and maybe very difficult, to remember the
    ascii equivalent.


Why are URNs affected?

- URNs advertise such things as grandfathering of namespaces.
    Maybe grandfathering could be a mechanism to deal with
    some internationalization issues.
- URNs are names. Names are intrinsically meaningful, and therefore
    need internationalization to be meaningful in the right context.
- URNs look a lot like URLs, so they may be affected in the same way
    as URLs by internationalization issues.
- Time is now. The earlier the direction for URL/N i18n is established,
    the easier it is to make it work consistently, and the less
    legacy issues have to be dealt with.
- Internationalization is an important issue in general, and not
    considering it nowadays is definitely not good practice.


What people might say agaist the internationalization of URL/Ns,
but is just not true:

- International URL/Ns create ambiguity.
    The ambiguity is about the same as with 0/O or 1/l/I.

- URL/Ns are just like phone numbers.
    Even for phone numbers, people try to create easy ways
    to remember them. And even if 99% of the URL/Ns are
    like phone numbers, not designed to be understod by
    any human reader, it's the rest of 1% that is important.

- Everybody should be able to type in an URL/N, everywhere.
    A lot of people have problems to type standard URLs
    on their keyboards because they are not used to
    the Latin alphabet. And does it matter whether you
    can type an URL/N, if you can't understand the contents
    of the resource it is pointing to anyway? If you
    understand the URL/N, but can't type it at the place
    you are, web servers can easily be constructed that
    provide such an input service. And finally, the
    information providers will be mature enough to
    decide what their audience prefers.


What are the problems for URL/N internationalization?

- Decide on character encoding and semantics.
    URLs currently allow to represent arbitrary octets (bytes).
    An octet 01000010 is represented as "B", an octet
    10001111 is represented as "%8F". Nothing in the URL
    spec says clearly that a "B" in an URL is actually
    supposed to mean a "B" in a context where one could
    ask what character that octet is representing
    (this means in almost all contexts, except e.g.
    for the data: URL).
    Hovewer, in fact the situation is much different
    for the "B" and the "%8F". The "B" is, although
    the spec does not require it, always just a "B".
    And the character "B" never turns up in another
    form in an URL than as a "B". For the "%8F",
    however, things are completely different. There
    is no standard or custom whatsoever saying what
    character (or part of a character) the octet
    represented by "%8F" could or should be, or by
    which octet or octets certain characters should
    be encoded. To some degree, such octets are used
    to denote some i18n characters, but if this works,
    it is only due to a lot of assumptions and guesswork
    on both client and server side.

    Some proposals tried to encode the relation between
    characters and octets as part of the URL itself
    (e.g. aka RFC 1522), which lead to very clumsy
    syntax and lots of other problems (esp. where exactly
    to put it and what it should apply to). An IMHO
    much better solution is to use an uniform encoding.
    Using UNicode/ISO 10646 and UTF-8, this could be done
    in a clear fashion, without affecting any ASCII
    URL/Ns, with large reserves for the future (2 Giga
    codepoints!), and with lots of other benefits.

- Specify in which cases which notation is to be used.
    E.g. on paper: International notation or %HH
    notation if unavoidable, on the line: preferably
    raw UTF-8, but %HH if a protocol prefers it,...

- Recommend ways for upgrades for the various schemes/
    protocols.

- Encourage browser and server implementors to go on with
    it.



Anyway, this is just a first mail to make you aware of the
issues. I look forward to an interesting and fruitful
discussion.

Regards,    Martin.

----
Dr.sc.  Martin J. Du"rst                ' , . p y f g c R l / =
Institut fu"r Informatik                 a o e U i D h T n S -
der Universita"t Zu"rich                  ; q j k x b m w v z
Winterthurerstrasse  190                 (the Dvorak keyboard)
CH-8057   Zu"rich-Irchel   Tel: [phone]
 S w i t z e r l a n d       Fax: [phone]   Email: [e-mail]
----